A condition is a chain of checks that must each prove true, in the right order, before a secret can come back.
You build that chain visually from reusable parts. Everything downstream, sealing and recovery, only ever assumes the conditions you picked can actually be proven.
The mechanism
Checks are chained, and order is part of the rule.
Each link is a check backed by a smart-contract address. A link only runs once the link before it has verified true, and each one hands the next its starting point. The whole chain has to resolve to true, in sequence, or nothing unlocks.
Openingreveal + anchor
Timelockblock height
IdentityZK check
All true
Each link passes its result forward. Break the order and the chain does not resolve.
The privacy property
A processor commits without learning what it committed to.
Conditions are referenced by contract address and blinded with random information, so a processor agreeing to a seal never sees the actual rule set. It commits to serving whatever chain the client proves, not to a policy it can read, judge, or be pressured over.
Addressed, not described
Each check points to a smart-contract address. The processor pulls and runs the bytecode at recovery time; it does not need the rule spelled out up front.
Blinded with randomness
Random information is folded in so identical conditions look different every time. Nothing about the rule leaks from what the processor sees.
Neutral by design
Because it cannot read the conditions, a processor cannot selectively refuse or be coerced based on their content. It only ever verifies proofs.
How you build one
Small proofs stack up into a template you fill in.
Conditions are composed, not coded from scratch. Individual proofs group into modules, modules gather into collections that hold the branching, and a finished collection becomes a template. At the end you just drop in your own values.
Level 1
Proofs
The atomic checks: a single ZK statement, a signature, a block-height test.
Level 2
Modules
Proofs grouped into a meaningful unit, like "verify this email" or "prove this passport".
Level 3
Collections
Modules arranged into the full flow, including the forks and alternative paths.
Level 4
Templates
A ready collection you fill in: email or passport details, key merkle roots, timelock times.
In the editor
Forks let several independent ways in coexist.
A collection can branch. That is how you express OR and time-dependent rules: satisfy any one path and the secret opens. One branch might be a live identity check, another a timelock that only becomes available much later.
Start
Identity now
open today
Timelock after 2y
fallback path
Unlocks
Batteries included
Common scenarios ship ready to fill in.
The SDK carries fully built templates for the patterns most people need. You provide the inputs; the proof plumbing is already wired.
ZKEmail
Prove control of an email address without revealing the inbox. Fill in the address and domain policy.
ZKPassport
Prove identity or age from a passport, in zero knowledge. Fill in the claim you want checked.
Timelocks
Gate a path on block height. Fill in the time, combine with a fork for dead-man-switch behaviour.
Once a condition is chosen, the rest of the protocol stops caring how it works. It only requires that the condition can be proven.